What's the use case for %ES_CFG%?

Thank you for response.
As a premise, this PR is not required for RetroPie's runcommand, but is intended for those who want to manually edit es_systems.cfg to add emulators.
To make their environment more manageable (make portable), such users will want to collect emulators like this:

users_toy_box\
  ├ EmulationStation_settings\
  │  ├ es_systems.cfg
  │  └ es_settings.cfg
  ├ RetroArch\
  │  ├ retroarch.exe
  │  └ configs\
  ├ the_emulator_A\
  │  └ the_emulator_A.exe
  ├ the_emulator_B\
  │  └ the_emulator_B.exe

And the EmulationStation settings have a fixed location (or --home), this can be resolved with a link.

~/.emulationstation -> users_toy_box\EmulationStation_settings

In this situation, by using %ES_CFG%, we can launch the emulator without writing the absolute path (portably) such as:

<command>%ES_CFG%/../the_emulator_A/the_emulator_A.exe %ROM%</command>

We could write it using an absolute path, but that would make it less portable.

Note @eib has submitted a similar PR #681 in the past, but although I used it as reference, I was unable to find a use for %ES_HOME%.

This isn't fully clear to me, but let me make a few more comments then.

Why not just stick to the home path and call it ES_HOME? The settings folder is meant to be for internal ES usage, it's not immediately clear to me why that is useful to have as a variable rather than home, unless there would be a use case to reading or manipulating the config files for some reason.

Thoughts on that?

Yes As you point out, I don't want to read or manipulate a configuration file.
In the previous example, I want to access the users_toy_box/ directory. (Not HOME -- my home directory contains a lot of things that are not ES or emulators, and I would like to keep them separate from the toy box.)

%ES_HOME% implements in #681 returns Utils::FileSystem::getHomePath() and be expand the following values:

1. The directory given with the option --home
2. Directory containing the EmulationStation executable file
3. User's home directory
4. Current directory

If we name this ES_HOME, what is ES_HOME, the directory what contains it? There may or may not be an executable file. It may or may not be the user's home. What is certain is that it will have a subdirectory .emulationstation, which will contain the ES's configuration file.
Can it be called 'HOME'? I think it would be more accurate to call it CFG.

Ok, but then I am really confused - if your goal is to make things portable, I was assuming you were taking ES with you somewhere in that users_toy_box folder. I agree we wouldn't call the settings folder ES_HOME, and that was not my suggestion.

I am really struggling to understand the use case that would have a portable config file and such - but not ES executable - and that you would need to make something depend on the configuration file folder. I mean, I understand that it works the way you're describing if you choose to implement it that way, but I'd imagine there would be more elegant solutions to accomplish it.

Still, since I am not someone who runs this in a portable setting and as such I might be clearly missing something in analyzing the whole use case, I will let others chime in, comment on this and provide guidance for reviewing it.

@pjft the entire idea is to have the emulator command be 'portable' by relying on some path portion that is calculated at runtime (and then expanded by EmulationStation's launching command code) - without starting ES through a script (.cmd) that would set %PATH% beforehand or employ other tricks. As @o-p-a said, if you want to 'access' (i.e. calculate) the users_toy_box path, you can do so by using the ES start path and then going up a level, so %ES_HOME/CFG/WHATEVER% would provide automatically this runtime expansion and thus be able to configure the path to the launching emulators from this relative path (see the example above).

Now, looking at the example give above, a more correct way would be to expand %ES_INSTALL% as the ES install folder and not use the config folder, which can be overrided through %ES_HOME% already. However, it still looks a bit hackish to me.

Thanks. Correct, I think I am suggesting what you are suggesting - having the variable point at the ES start path (which for me was ES HOME, but I get that it can be a loaded label). I was just struggling with having the variable point at the settings folder instead of the start path, that was my main point of contention. It might have come across incorrectly.

Hi, there... been a while. ;)

I notice my PR #681 and thus the issue of portability (I reported in #680) are still open. (Granted I appear to have merge conflicts.)

I see @o-p-a is interested in a shortcut to the ES configuration directory. I was interested in the ES executable directory -- which in code is called "home path", so I referred to it as the "ES Home directory". And we are both interested in shortcuts to the ROM directory. Can I propose a ... merging of ideas?

• %ES_HOME% == whatever the code (already) determines is the "home path"
• %CFG_DIR% == the directory of the ES config
• %ROM_DIR% == the directory containing the ROM

... the reason I opened #680 was to give the users of EmulationStation (such as myself) the flexibility to use it/organize it our way.

P.S. @o-p-a To me, something called "ES_CFG" sounds like the actual config file. If you're looking at the directory containing the config, I think "CFG_DIR" sounds cleaner. Just my thoughts. ;)

Thank you everyone for quick responses! (and sorry for my late reply)

@pjft I apologize for confusion by not telling that I installed EmulationStation to the absolute path C:\Program Files(86), following Windows convention (hence the ES binary itself is not portable).
(I understand that ES is portable actually and doesn't necessarily need to be installed in like Program Files or /opt/retropie/.)

As I mentioned above, I couldn't imagine what %ES_HOME% would be used for, but that's because what %ES_HOME% refers to varies depending on the situation.
However, if there was tag that always pointed to the "ES executable directory" regardless of the situation, I thought it would be worth for adding.

Based on the discussion, I would like to suggest the following:

• %ROM% - absolute path to the selected ROM
• %BASENAME% - "base" name of the path to the selected ROM
• %ROM_RAW% - unescaped, absolute path to the selected ROM

...These are the existing tags. In addition to these, how about adding the following:

• %ROM_DIR% - The directory name of the selected ROM, without the basename and extension
• %ES_CFG% → %CFG_DIR% - Regardless of the directory structure or command line options, the directory containing the configuration file
• %ES_INSTALL% → %INSTALL_DIR% - Regardless of the directory structure or startup options, the ES executable directory

I think @eib's point about %ES_CFG% is very valid. Also, when enum them like this, I think it would be more regular to %ES_INSTALL% as %INSTALL_DIR%.

If there are no objections, I'll add a commit along those lines soon. Thanks everyone.